Lambda the Ultimate

For a long time now, on and off, I've been writing a Lisp tutorial for regular programmers. The idea was not to explain intricate details of Lisp, but help people understand what exactly the nature of the language is, and why some of its features are great for modern software development.

I'm very interested in feedback so I can improve upon the tutorial and explain things people still don't understand. You can read it here.

Are there any links to online lectures for a course on programming languages? (apart from SICP lectures)

Being on the subject of virtual classes: a new article Multidimensional Virtual Classes by Vaidas Gasiunas, Klaus Ostermann and Mira Mezini.

Virtual classes and static type systems for them are gaining attention because of their support for variations on functionality that involves several classes. Like the majority of object-oriented languages, previous languages with virtual classes use single dispatch for dispatching virtual classes. We show that single dispatch limits the range of the variations supported by virtual classes and propose
multidimensional virtual classes, which combine virtual classes with multi-dispatch, and show how this combination improves their support for variability. We present a formal semantics of a language with support for multidimensional virtual classes and discuss some issues related to the design space of such languages.

Can anyone find this online, or send me a copy? All links I find are 404...

I sure hope Darius is reading the LtU forum at the moment...

The ACM Special Interest Group for Array Programming Languages is expanding it's scope beyone classic APL. Papers on Lush implementation or array oriented applications would be appropreate.

ANNOUNCEMENT

Issue 34:3 of APL QUOTE QUAD is now closed and ready for publishing.
We are now starting to process the next issue (34:4), and we need new
material. Therefore, I am sending this

CALL FOR PAPERS

APL QUOTE QUAD

The next issue of APL Quote Quad is being designed. Prospective authors
are encouraged to submit papers on any of the usual subjects of
interest related to Array-Processing Languages (APL, APL2, J,
and so forth).

Submitted papers, in Microsoft Word (.doc), Rich Text Format (.rtf),
Openoffice format (.scw), Latex (.tex) or Acrobat (.pdf)
should be addressed to

Manuel Alfonseca
Manuel.Alfonseca@ii.uam.es

Care must be taken to make the submitted papers self-contained,
eg. if they require special APL typesettings.

The tentative time limit for the new material is May 31st, 2006.

I am designing a dialect of Joy called 'Big Cat'. Like Joy, Big Cat is a pure stack based functional language (or concatenative language, if you like the term). This means that every function takes a single stack as a parameter, and returns a new stack as a result. Most programs expect a certain stack configuration, so I am devising a syntax for expressing the desired type configuration.

One of the changes is the introducction of a type notation for operations. Here is my current proposal:

  swap (T, U) => (U, T);
  dup (T) => (T, T);
  dupN (int, T) => (T*);
  pop (T) => ();
  popN (int, T*) => ();  
  if (() => T, () => U, bool) => (U|T);

I welcome feedback, and suggestions. Let me know if the syntax is not intuitive and you need clarification, thanks!

Abstract: In object-oriented languages, it is easy to extend data by defining new classes, but it is difficult to add new functions. In functional languages, the situation is reversed: adding new functions poses no problems, but extending data (adding new data constructors) requires modifying existing code. The problem of supporting both directions of extensibility is known as the expression problem. We present open data types and open functions as a lightweight solution to the expression problem in the Haskell language. The idea is that constructors of open data types, and equations of open functions can appear scattered throughout a program. In particular, they may reside in different modules. The intended semantics is as follows: the program should behave as if the data types and functions were closed, defined in one place. The order of function equations is determined by best-fit pattern matching, where a specific pattern takes precedence over an unspecific one. We show that our solution is applicable to the expression problem, generic programming, and exceptions. We sketch two implementations. A simple one, derived from the semantics, and one based on mutually recursive modules that permits separate compilation.

I don't know if it's just me or whether there was an upper limit put on the number of messages being cranked out per page? When I click on a response I get two problems: First, only 10 messages from the very top of the thread are displaying - albeit with a next page button at the bottom. Second, the link doesn't go to the message I click on unless it happens to be in one of the first 10.

We all love the Language vs. IDE flame-fests. But I'd like to be a little more constructive and try to see what kind of tools people actually use. The concrete question I'd like you to answer is:

What editor or IDE are you using when programming?

Please also say a few words about why you use your particular editor and any particular functionality that you like and which help you in your everyday programming.

The answer will of course be influenced by what language you are using. And that's totally fine.

In a similar vein to John Carter's recent submission, here's an attempt to attack the complexity problem: Out of the tar pit

Abstract: Complexity is the single major difficulty in the successful development of large-scale software systems. Following Brooks we distinguish accidental from essential difficuly but disagree with his premise that most complexity remaining in contemporary systems is essential. We identify common causes of complexity and discuss general approaches which can be taken to eliminate them where they are accidental in nature. To make things more concrete we then give an outline for a potential complexity-minimizing approach based on functional programming and Codd’s relational model of data.

They basically advocate minimising mutable state, moving any mutable state that remains into relations, and specifying the behaviour (i.e. manipulation of relational data) in a declarative/logical/purely-functional language.

Pros: the first half of the paper is a reasonable review of the types and causes of complexity in software.

Cons: lack of any implementation, other than a Scheme prototype of the relational bits, I think (see footnote 25). No source code. Lack of detail about interfacing with external systems.

Here's a link to Ben Moseley's FRP page, where you can find the paper, plus presentation slides and a discussion group.